Date: Fri, 17 Sep 93 04:30:01 PDT 

From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu> 
Errors-To: Packet-Radio-Errors@UCSD.Edu 

Reply-To: Packet-Radio@UCSD.Edu 

Precedence: Bulk 

Subject: Packet-Radio Digest V93 #273 

To: packet-radio 


Packet-Radio Digest Fri, 17 Sep 93 Volume 93 : Issue 273 


Today's Topics: 
9600 baud - commercially available? 
Digipeater (3 msgs) 
HELP: PMP to HTX202 
HF packet for IC720A 
I need info on getting started with packet radio 
packet help 
packet radio encryption 
RACES packet terminal pgm 


Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu> 
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Wed, 15 Sep 1993 11:31:18 GMT 

From: dog.ee.lbl.gov!agate!howland.reston.ans.net!gatech!kd4nc!ke4zv! 
gary@network.ucsd.edu 

Subject: 9600 baud - commercially available? 

To: packet-radio@ucsd.edu 


In article <2242@arrl.org> bbattles@arrl.org (Brian Battles WS10) writes: 
>In rec.radio.amateur.digital.misc, richgi@microsoft.com (Richard Gillmann) 
>writes: 

>>Can a 9600-baud packet station be set up entirely out of commercially 
>>available items (not kits)? This would have to include a TNC, a 9600-baud 
>>modem and a VHF ox UHF radio. 

> 

> Gracilis sells the PackeTwin system with a plug-in card for your 
>IBM-compatible PC. It includes a 'DSY modem (9600 or 19,200 bit/s) and 


>a TEK 440-MHz transceiver (2 W). Handy! (Mine was working fine into the local 


Note, the Gracillis card does xnot* include a WA4DSY (aka GRAPES) 56 kb 

RF modem. It does include provisions for *driving*x one externally through 
one of it's ports. 1200 baud, 2400 baud, 9600 baud, and 19.2 kb, daughter 
card modems are available for the card's other port. They're actuallly made 
for Gracillis by Kantronics. The Tekk radio is small, originally intended 
for board mounting. It is powered and driven off the daughtercard modem. 


Gary 
Gary Coffman KE4ZV |"I£ 10% is good enough | gatech!wadmei!ke4zv! gary 
Destructive Testing Systems | for Jesus, it's good | uunet!rsiatl!ke4zv! gary 
534 Shannon Way | enough for Uncle Sam."| emory!kd4nc!ke4zv! gary 

| | 


Lawrenceville, GA 30244 -Ray Stevens 


Date: Wed, 15 Sep 1993 11:23:42 GMT 

From: dog.ee.lbl.gov!agate!doc.ic.ac.uk!uknet!icsbelf!mark@network.ucsd.edu 
Subject: Digipeater 

To: packet-radio@ucsd.edu 


In article <O1H2YIIJ8KDDE91XURZ@delphi.com> WGOB@delphi.COM writes: 
>ON 13 Sep 93 14:30:39 GMT 
>FROM: ogicse!emory!kd4nc!ke4zv!gary@network.ucsd.edu 


> 
>In response to: 

>> How a digipeater work ? Is it same as a repeater ? 
> 


>You wrote: 

>> A digipeater is a store and forward relay node...... 

> 

>If you would substitute "network node" (netrom node) in each instance 
>where you used "digipeater", your answer would be reasonably accurate. 
>It's no wonder newcomers are confused when even the "experts" don't know 
>to use the correct terminology. 


I think Gary was right... 


>Digipeating is an instantaneous retransmission mode available 
>(unfortunately) as a "feature" on virtually all TNCs. 


No TNC I know of "Instantaneously" retransmits what it hears. They all listen 
to the the entire frame, STORE it (of course), mangle the header appropriately, 
and then queue it for transmission. Most software can be configured to give 
digi'd frames a "higher priority", ie they get sent sooner than ordinary frames. 


>Digipeaters 

>do xNOT* store and forward; they do xNOT*x test the frequency prior to 
>transmitting; and only at the destination station is the packet frame 
>tested for accuracy. 


They DO store and forward, and they DO check the frequency (by default anyway). 
Not that on most TNC's you can disable the frequency checking. BAD idea! 


What you are describing is the output from a modem attached (usually via 
some more hardware) to the input of another modem. 


If your description was right, then every TNC with digipeating enabled would 
retransmit xeverythingx it heard. Can you imagine what the effect would be? 


>Digipeating, as a mode, can be supported by most 
>netrom compatible nodes. Fortunately, it can also be disabled, as it 
>should be in virtually all cases. 


Sure, but not in the 'instantaneous' way you describe. 


A Network Node (ie netrom, or netwrong as many would have it) does a 

completely different thing. It takes layer 2 frames from the user and (often) 
packages them into layer 4 frames to send to other netrom nodes. The remote 
node does the opposite. Netrom nodes support digipeating too (STORE AND FORWARD) 
but lots of ‘em have it turned off. 


-Mark 

Mark Willis Internet: mark@icsbelf.co.uk 

ICS Computing Group Ltd. Packet: GIOPEZ@GB7TED.#63.GBR.EU 
Belfast AmprNet: 44 .131.15.3 


Northern Ireland 


Date: Wed, 15 Sep 1993 16:31:35 GMT 

From: sdd.hp.com!usc!howland.reston.ans.net!vixen.cso.uiuc.edu! 
newsrelay.iastate.edu!news.iastate.edu! jvp@network.ucsd.edu 
Subject: Digipeater 

To: packet-radio@ucsd.edu 


In <OLH2YIIJ8KDDE91XURZ@delphi.com> WGOB@delphi.COM writes: 


>ON 13 Sep 93 14:30:39 GMT 
>FROM: ogicse!emory!kd4nc! ke4zv!gary@network.ucsd.edu 


> 
>In response to: 
>> How a digipeater work ? Is it same as a repeater ? 
> 
>You wrote: 
>> A digipeater is a store and forward relay node...... 
> 
>If you would substitute "network node" (netrom node) in each instance 
>where you used "digipeater", your answer would be reasonably accurate. 
>It's no wonder newcomers are confused when even the "experts" don't know 
>to use the correct terminology. 
PAV AV AVAVAVAVATAS 


And you're one of these experts? 


>Digipeating is an instantaneous retransmission mode available 
>(unfortunately) as a "feature" on virtually all TNCs. 


Wrong. Digipeating is not instantaneous. 
>Digipeaters do *xNOT* store and forward 
Wrong. Digipeaters *DO*x store and forward. 
>they do xNOTx test the frequency prior to transmitting 
Wrong. Digipeaters *DO*x test the freq prior to retransmitting 


>and only at the destination station is the packet frame 
>tested for accuracy. 


Right. Only the destination station does a CRC check and ack's the frame. 


>Digipeating, as a mode, can be supported by most 
>netrom compatible nodes. Fortunately, it can also be disabled, as it 
>should be in virtually all cases. 


Not necessarily. There's a lot less overhead by simple digipeating. 
The distinction between digipeater and node is in the acknowledgement 
packets, and path finding. A digipeater simply passes the frame on 
to the next digipeater or the destination. The destination station is 
responsible for sending an acknowledge packet back, which gets digipeated 
back to the source station. Nodes give a local acknowledgement of the 
packet when they receive it. That way, the destination has to only send 
the acknowledgement back to the last node. There's a lot less chance of 
a lost packet slowing you down. 


But in a clear channel, digipeating is more efficient if you only go 
one or two hops. If the chance of packet loss is very low, this is more 


efficient because the message bounces straight through to the destination, 
without having to wait for a local CRC check and acknowledgement. I have 
seen many cases where simple digipeating has a higher throughput than a node. 
The there are also cases where a node has higher thoughput. It depends on 
your environment. 


| Jim Van Peursem - Dept of EE and CprE - Iowa State University | 
| Ames, IA 50011 - internet: jvp@iastate or tools1.ee.iastate.edu | 


Date: Wed, 15 Sep 1993 11:44:39 GMT 

From: haven.umd.edu!darwin.sura.net! gatech!wa4dmei! ke4zv! gary@ames.arpa 
Subject: Digipeater 

To: packet-radio@ucsd.edu 


In article <O1H2YIJ8KDDE91XURZ@delphi.com> WGOB@delphi.COM writes: 
>ON 13 Sep 93 14:30:39 GMT 
>FROM: ogicse!emory!kd4nc!ke4zv!gary@network.ucsd.edu 


> 
>In response to: 

>> How a digipeater work ? Is it same as a repeater ? 
> 


>You wrote: 

>> A digipeater is a store and forward relay node...... 

> 

>If you would substitute "network node" (netrom node) in each instance 
>where you used "digipeater", your answer would be reasonably accurate. 
>It's no wonder newcomers are confused when even the "experts" don't know 
>to use the correct terminology. 


Out of the horse's mouth. :-) 


>Digipeating is an instantaneous retransmission mode available 
>(unfortunately) as a "feature" on virtually all TNCs. Digipeaters 

>do *xNOT* store and forward; they do xNOT*x test the frequency prior to 
>transmitting; and only at the destination station is the packet frame 
>tested for accuracy. Digipeating, as a mode, can be supported by most 
>netrom compatible nodes. Fortunately, it can also be disabled, as it 
>should be in virtually all cases. 


Unfortunately it's xyoux who is confused. Digipeating xis*x store and 
forward. The frame is not relayed until it has been completely 
received, checksummed, and the header inspected to see if the frame 
is requesting relay by the digipeater. The digipeater then obeys 


channel access protocol and waits until the channel is free, within 
the limits of hidden terminal syndrome, before retransmitting the 
frame. 


A Netrom node behaves somewhat similarly, except that it transmits 

an immediate acknowledgement to the originating station before 
retransmitting the frame now encapsulated in a Netrom frame. Netrom 
offers automatic routing rather than depending on the source routing 

of digipeaters by establishing a circuit table internally. What 

netrom does xnotx offer is end to end acknowledgement that a frame 
actually reaches destination. It only acknowledges that *it* received 
the frame from the orignating station. It will teardown the connection 
after a time if it fails to deliver frames, but that gives little 
information to the originating station about the status of the transfer. 


Netrom is useful, thanks to it's auto routing and hop by hop acknowledgement 
internally, but it's not fundamentally different from the operation of 
a digipeater in that it too is a store and forward node. 


Gary 
Gary Coffman KE4ZV |"I£ 10% is good enough | gatech!wadmei! ke4zv! gary 
Destructive Testing Systems | for Jesus, it's good | uunet!rsiatl!ke4zv! gary 
534 Shannon Way | enough for Uncle Sam."| emory!kd4nc!ke4zv! gary 

| | 


Lawrenceville, GA 30244 -Ray Stevens 


Date: Wed, 15 Sep 1993 21:02:47 GMT 

From: gsm001!gsm001.mendelson.com! gsmlrn@uunet.uu.net 
Subject: HELP: PMP to HTX202 

To: packet-radio@ucsd.edu 


In article <"15-Sep-93.8:52:46".*.David_Mensing.Roch817@Xerox.com> 
mensing.roch817@xerox.com writes: 

>I am looking for someone who has had experience with connecting a Poor Man's 
Packet 

>modem to a Radio Shack HTX202 2 meter HT. 

> 

>I have been using this PMP modem with an ICOM O2AT for over a year without any 
>problems. When I try using the HTX202 with this same PMP modem, it won't key the 
>radio. I know that the mic plugs are the same because I use the same speaker mic 
on 

>both rigs. By the way, I can receive packets with the HTX202. 


I had a similar problem with an mfj tnc. I called mf£j and was told to 
use a 3.3k, or if that did not work a 2.2k, resistor instead of the 48k 


or so one used for Icom. 


If I remember correctly it goes between ptt and the radio's audio in. 
BTW this cable also works fine with an Icom ic-2sat. 


73, 


Geoff. 


Geoffrey S. Mendelson N30WJ 
(215) 242-8712 
gsm@mendelson.com or uunet! gsm001! gsm 


Date: Wed, 15 Sep 1993 13:37:32 UTC 

From: pipex!sunic!trane.uninett.no!news.eunet.no!nuug!news.eunet. fi! 
anon. penet.fi@uunet.uu.net 

Subject: HF packet for IC720A 

To: packet-radio@ucsd.edu 


I have a MFJ1270B with an add on tuner that I am trying to hookup 
to my Icom 720A for HF packet operation. The problem I am having 
is that I can not seem to drive the audio circuits of the 720. 
The radio PTT is keyed and the radio goes into transmit but no 
audio is present, FYI receive works fine. Has anyone encoutered 
this type of problem and can tell me what to do I would be very 
greatful. Please post the resonse to my email account 
(scottm@csg.mot.com) 

thanks 


To find out more about the anon service, send mail to help@anon.penet. fi. 
Due to the double-blind, any mail replies to this message will be anonymized, 
and an anonymous id will be allocated automatically. You have been warned. 
Please report any problems, inappropriate use etc. to admin@anon.penet.fi. 


Date: Mon, 6 Sep 1993 20:40:53 GMT 

From: boulder! cnsnews!spot.Colorado.EDU! koberg@uunet.uu.net 
Subject: I need info on getting started with packet radio 
To: packet-radio@ucsd.edu 


I'm interested in learning all about what Packet Radio is, what I 
need to get started, perhaps how to build my own stuff, what 


software is available, 


etc. 


In other words, everything and anything that's out there, information 


wise. 


Respond via e-mail to koberg@spot.colorado.edu 


Thanks mucho. 


Date: Wed, 15 Sep 93 17:10:44 GMT 
From: pipex!uknet!mcsun!sun4nl!hacktic!utopia.hacktic.nl!consolat.hacktic.nl! 
zerial.hacktic.nl!zerial@uunet.uu.net 


Subject: packet help 


To: packet-radio@ucsd.edu 


You might get more response if you mention your email address. Many 
of us read the news posts as digests from ucsd.edu and a lot of the 


message is about 80 chars of site!site!site!site... 


> 
> 
> message header is deleted to save space. The "From:" line on your 
> 
> 


Ah yes, I forgot! My mail adress is zerial@zerial.hacktic.nl 
And as far as my from line's concerned, I have NO idea how 


it got to be that long. 


(my boss) 


. I'll sure ask somebody though. 


Hope to find some reply's soon, 


Zerial. 


Date: 17 Sep 93 10:11:39 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: packet radio encryption 
To: packet-radio@ucsd.edu 


<g4wrw@g4wrw.ampr.org> 


>In the first category 
>modems (and others no 
>less bandwidth, 7plus 
>difficult for someone 


Dave, G4WRW wrote: 


comes things like the scramblers used on G3RUH/K9ING 
doubt), using PKZIP to compress a file so it takes 


and UUcode etc. The fact that most of these make 
else to read the contents is purely coincidental 


it 


Well, Radio Eriwan's response would be: in principle/theory yes, 

but ... the files which really cause trouble are of Jumbo size. 

In order to squeeze them through HF links and to circumvent size 
limitations they are split up into many smaller chunks. 

It is not uncommon in the German PR network that the check list of a BBS 
is flooded by some 40..70 split files used for dissemination of a single 
400K SFX thing which won't sfx until all have been recorded intact. 
Before that, everything received can be accounted to as noise. 

Can you think of a more effective encryption than just omitting or 
holding back one of these 40 parts of a large ZIPped file? 

In other words, transparency is lost completely with compressed and split 
files, unless a sysop reconstructs them and checks them for integrity 
be £orxre he forwards any part further. This would also make any 
manipulation impossible. 


An important question is, whether it is fair and feasible to put this 
additional work load onto the shoulders of sysops and whether they are 
prepared to do it. 


Similar considerations as with split files apply to correction mechanisms. 
A working FEC, when applied to an encoder/decoder, is transparent if and 
only if the original data content can be regenerated immediately for one 
hop, i.e. in a direct digipeater-to-digipeater or BBS-to-BBS configuration. 
All long-loop applications seem vulnerable to manipulation and are also 
inefficient from a systematic point of view, because they very often make 
it difficult, if not practically impossible to locate the point of failure. 


And then there are gimmicks like 7plus. From its first to the present 
version 2.1, after more than 2 years unlike advertised, 7plus is not 
capable to detect all single bit errors let alone to correct them, 
despite of the publication of the underlying design error in July 91. 
This is an invitation to amateur cryptographers to manipulate the two 
weak bits per line to produce 24(lines*2) permutations which remain 
undetected when decoding. A professional cryptanalist would probably have 
little difficulty to break this code, but at radio amateur level the 

type of encryption is cumbersome to crack, although probably caused by 
mere incompetence. In any case, even involuntary encryption is illegal. 


I hope that I could contribute some technical arguments in favor of Jim, 
4X1RU, to keep his important links clean from any 7plus and other 
intransparent binary or encoded files. 


Dietmar DJ4RX @ LXOPAC.LUX.EURO 


If you want to answer directly, please use the packet radio address above. 


p.s. I leave it as a quiz for those interested 
to find out the displacements of the two foul bits. 


Date: Thu, 16 Sep 93 09:17:46 GMT 

From: news!dg-rtp!webo!dg-webo.webo.dg.com!abracket@uunet.uu.net 
Subject: RACES packet terminal pgm 

To: packet-radio@ucsd.edu 


In article <11SEP199315300152@bioch.tamu.edu> mwhitsitt@tamu.edu writes: 

>A while back, there was some mention of a packet terminal program specifically 
>for use in RACES applications. I never saw any more about it's availability an 
>such. Any information would be appreciated. 


> 
Mabye if someone has it they could post the information... 
Thanks 
73-al 
Did I drop my .sig in the coffee??? Al Brackett 
N1IQQ @ KAIRCI.RI (for those that know) abracket@dg-webo.webo.dg.com 


Work For Peace / Plan For Conflict / You can't WIN if You don't TRY 
[insert] Standard Disclamer Here< > BLESS / PEACE 


End of Packet-Radio Digest V93 #273 
KK KKK KKK KKK KIKI KKK IK IKKE KIRK 


